The notifier isn't a right place for panic checks, and the dmesg tool handles more scenarios. The notifier cannot fail the test case, so the results is hard to associate with the failed cause.

1. If the purpose wants to capture kernel panic or call trace in some test cases, you can always call Dmesg.check_kernel_errors in the test case.
2. If it wants to capture errors in general, you can check what LISA have now, and may apply an extra check switch, so any kernel error happens, fail the just ran test case and mark the env bad.

The notifier isn't a right place for panic checks, and the dmesg tool handles more scenarios. The notifier cannot fail the test case, so the results is hard to associate with the failed cause.

1. If the purpose wants to capture kernel panic or call trace in some test cases, you can always call Dmesg.check_kernel_errors in the test case.
2. If it wants to capture errors in general, you can check what LISA have now, and may apply an extra check switch, so any kernel error happens, fail the just ran test case and mark the env bad.

@squirrelsc Thanks for the comment. The purpose of the Notifier is not to fail the test cases in case of an OOPS/Kernel Error but to simply save the detections in a file, which can then be later utilized for notification purposes. There are many tests which do not check the Dmesg logs for issues since the purpose of the test case might not necessarily need it - though it was still important to check Dmesg logs for each of the tests without actually failing them.